Broadly speaking, the present invention relates to providing quality of service parameters for data streams. More particularly, the present invention provides a system for implementing quality of service parameters for multicast flows at a cable network headend system. The relevant component in the present invention is the cable network headend, which interprets quality of service parameters in a multicast stream and applies them to packets transmitted onto the cable network.
Quality of service is a qualitative and quantitative set of parameters used to maximize efficiency and specify levels of service in a network. System administrators, service and content providers, among others, can effectively control network usage, reliability, and resources by specifying quality of service parameters. These parameters may include minimum unit delay, maximum unit delay, peak bandwidth, mean bandwidth, minimum bandwidth, latency, priority, jitter, response time, and burst dispersion. Quality of service can also be specified by predefined levels of service. These levels may include controlled delay (where a maximum forwarding delay is set), guaranteed service (where bit rates are predefined), and predictive service (where bit rates are guaranteed for a certain portion of the traffic). Quality of service specifications are particularly important for providing streaming video and audio while still retaining enough bandwidth for other forms of network traffic.
Data Over Cable Service Interface Specification 1.1 (DOCSIS 1.1), includes functionality that allows administrators to provide quality of service for traffic flowing into or out of a cable network and is hereby incorporated by reference for all purposes. The cable modem termination system (CMTS) and its associated routing mechanism connect cable modems to an outside network such as the Internet.
DOCSIS provides an extensive set of quality of service parameters for cable networks. These parameters include not only the ability to specify levels of service, but also provide for the ability to differentiate service for different types of traffic, such as voice or video. Since DOCSIS only provides quality of service parameters on a per cable modem basis however, these parameters are only available for unicast or point-to-point routing. For example, where one client on an external network sends a data file to a client within a cable network, DOCSIS allows the CMTS to determine what quality of service parameters should be associated with the data file packets being transmitted to the cable modem within the cable network.
FIG. 1 shows packet processing capabilities specified in DOCSIS 1.1 at a CMTS 100. A packet 103 arrives from an external network 101 such as the Internet. The CMTS 100 recognizes that the destination of the packet lies within the cable network of the CMTS 100. The CMTS 100 locates the recipient cable modem based on packet information and information stored within the CMTS 100. This packet 103 is introduced with its associated cable modem information into a classifier 109. This classifier 109 categorizes the packet based on a classifier list 111 for that particular cable modem. The classifier list 111 may categorize the packet based on criteria such as IP address, protocol type, or port number. Typically, these criteria are chosen to distinguish between different types of traffic such as telephony, web traffic, video, etc. Once the packet has been classified, the CMTS 100 assigns a flow to the packet based on the flow list 113 associated with the particular cable modem. This flow list 113 specifies groups of quality of service parameters. This packet now associated with a flow 115 has quality of service parameters that govern whether the packet should be transmitted downstream, delayed, or dropped. Various traffic shaping and policing algorithms are used in making this determination.
For many applications, it is necessary for one client to send the same information to multiple clients. Although it is possible to send the information to each of the clients point-to-point, this strategy would be a drain on network resources. For example, a unicast transmission of a data packet to a group of 1000 recipients would require periodic transmission of 1000 packets, even though many of the packets would end up traversing the same links. Broadcast transmission of the same packet to a group of 1000 recipients would work if the number of recipients was not that much smaller than the number of total clients on the network. However, in large networks with numerous subnetworks, broadcasting would be a waste of resources for all of the clients not interested in the information. Multicast transmission would be the ideal solution where a data packet needs to be transmitted to a large number of recipients who comprise a small number of total clients on the network. To send a packet to 1000 recipients, multicast transmission only requires a single packet be delivered, although the packet may be replicated at the forks in a multicast delivery tree.
Multicasting was developed to deal with the inefficiencies inherent in broadcasting or point-to-multipoint messaging. A multicast stream would be placed onto a network at a given time by a video server, for example. Although this multicast stream would reside on the network, it would not be transmitted to an end user until an individual client made a request to receive the video stream. If a cable modem user requested the multicast stream, the CMTS or its associated multicast router would seek out and retrieve the stream on the network and prepare to send the information downstream to the cable modem user.
While DOCSIS provides extensive functionality for specifying quality of service provisions for unicast or point-to-point transmissions, DOCSIS provides little or no functionality for specifying quality of service parameters for a multicast stream intended to be received by a number of clients. This shortcoming is particularly serious because both multicasting and cable are technologies that are capable of bringing true streaming video content to the end user.
DOCSIS 1.1 has no provisions for applying different quality of service parameters to different multicast streams. DOCSIS 1.1 only provides that multicast streams will be transmitted based on the best effort model of delivery. The CMTS under this best effort model of delivery essentially guarantees nothing. The CMTS makes no commitment about specific treatment of packets of a certain flow. A transmitted data stream gets what bandwidth is available. If the CMTS and its associated router are congested at the time the video stream arrives, a substantial portion of the video stream packets may be dropped. The best effort model often is sufficient for traditional data applications such as text and graphics transmissions, FTP, telnet and other uses where timeliness is not of the essence. However, new kinds of applications such as video-on-demand or video teleconferencing are highly sensitive to time delays. The traditional best effort method of increasing packet delay in order to improve fairness and correct delivery is currently incapable of reliably transmitting on-demand high bandwidth streams.
Many video content providers may wish to provide very specific video quality levels for their receivers. Video conferencing may need to specify minimum bandwidth requirements, maximum packet delays, or a host of other requirements. DOCSIS does not provide any of these capabilities for multicast transmissions cable or hybrid fiber coaxial networks. At most, DOCSIS 1.1 supports multicast transmissions using IGMP, but without any quality of service guarantees.